Bard College

Bard Digital Commons

!)%*,,*&!.-+,%)# , ) !,#, /.!!)%*,,*&!.-



Context Aware Application Using Beacons

Abdullah Nasim

Bard College

4%-+!)!--%-,*/#$..*2*/"*,",!!) *+!)!--2.$!,

) !,#, /.!!)%*,,*&!.-., %#%.'*((*)-.$-!!)

!+.! "*,%)'/-%*)%)!)%*,,*&!.-+,%)#2)/.$*,%3!

 (%)%-.,.*,*", %#%.'*((*)-*,(*,!%)"*,(.%*)+'!-!

*).. %#%.'*((*)-, ! /

!*((!) ! %..%*)

-%( /''$*).!1.0,!++'%.%*)-%)#!*)- Senior Projects Spring 2016. +!,

$5+ %#%.'*((*)-, ! /-!)+,*&-

Context Aware Application using Beacons

A Senior Project submitted to

The Division of Science, Mathematics, and Computing

Bard College

Abdullah Nasim

Annandale-on-Hudson, New York

May, 2016

Abstract

With the growing popularity of mobile computing, as well as the increasing demand for

location-based services, this paper introduces a design and implementation of a location-

aware system using Beacons. This project comprises three parts: a web application, back-

end server and a mobile application client. The web application serves as a content man-

agement system by allowing users to manage projects, input data and create associations

between Beacons and data. The backend server contains application logic and a database.

The mobile application client interacts with the Beacons and provides location-speciﬁc

services.

Contents

Abstract 1

Dedication 5

Acknowledgments 6

1 Introduction 7

1.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Background 10

2.1 Context Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Location Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Current Applications of Beacons . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Challenges with Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Debunking the Myths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7 Alternative to iBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Project Requirements 22

3.1 Deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Use Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 System Design 25

5 Technical Implementation 29

5.1 Estimote Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Contents 3

5.2 Data Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Application Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3.1 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3.1.1 Models.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3.1.2 Views.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.1.3 Templates Folder . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.1.4 Flask-Security . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3.1.5 Flask-WTF . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3.1.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.2 Web API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4 Presentation Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4.1 Beacon Ranging and Monitoring . . . . . . . . . . . . . . . . . . . . 43

5.4.2 GET requests to server . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6 Results 52

6.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 Conclusion 55

7.1 Limitations of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Appendices 58

A Comparison of Location Systems 59

B Database Schema 61

C Table showing all the HTML ﬁles and respective controller methods in

views.py 63

D Images of Web application rendered on browser 65

E Web Application Requirements Document 68

Bibliography 71

List of Figures

3.2.1 Use Case Diagram for Web Application . . . . . . . . . . . . . . . . . . . . 23

3.2.2 Use Case Diagram for Mobile Application . . . . . . . . . . . . . . . . . . . 24

4.0.1 2-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.0.2 3-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.0.3 Initial System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.0.1 Final System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Dedication

To my parents and my homeland, Pakistan.

Acknowledgments

I would ﬁrst like to thank Ms. Heidi Knoblauch for giving me the chance to work with

Experimental Humanities on this project. I also want to thank Ryan Sablosky for his

constant patience and help throughout this process. I also want to extend my heartfelt

gratitude to my supervisor Sven Anderson whose guidance and encouragement were very

vital in completing this project.

Introduction

1.1 Problem Description

In current times, the internet and mobile technology allow anyone with a smartphone to

access a vast amount of information. Recent studies show that in the U.S. web surﬁng on

mobile devices accounts for 52% of the time spent consuming digital media [1]. Another

study reveals that the ownership of smartphones exceeds that of desktops and laptops

around the world [2]. With increased ownership of smartphones and high-speed internet,

the social trends and habits of consumers have signiﬁcantly changed. Consumers demand

information on their mobile devices when and where they need it. This has led to devel-

opment and research in the ﬁeld of mobile computing, in particular, context-aware mobile

applications. Context-aware mobile applications can serve to anticipate the needs of the

consumer and provide services based on their location. There have been several systems

developed in the past few decades aiming to provide location of consumers and objects.

Currently, the Beacon technology has become one of the major emerging technologies that

is being used around the world to enable mobile applications to provide location-based

services.

1. INTRODUCTION 8

1.2 Project Goals

The goals of this project are to create an open-source Android mobile application and a

web application. This project is under the department of The Experimental Humanities

(EH) at Bard College. We plan to create an interactive exhibition about Mass Incarceration

using Estimote Beacons. Estimote Beacons are tiny computers that broadcast radio signals

and can be used to produce context-aware mobile applications. Smartphones within range

of the beacons can detect and receive the broadcasted signals. Mobile applications can

be developed that act upon these signals and push notiﬁcations, images, text, sound, and

videos depending on the functionality of the app. We intend to develop a mobile application

that will allow participants to receive information regarding Mass Incarceration as they

explore the installation. The supporting web application serves to manage the project and

content which is delivered by the mobile application. The installation will provide digital

stories about the impact of incarceration on New York City neighborhoods and spark

conversation about how Beacons can be used to raise awareness about social issues.

The ultimate goal is to produce an open source system consisting of a web application

and a mobile application. The web application will allow users to self-host their own

Beacon-based projects and the mobile application will be automatically conﬁgured to

provide location-based services according to the project setup. Therefore the system can

be replicated and used by others to create context-aware mobile applications with little

or no modiﬁcation aside from the input dataset.

1.3 Contributions

The idea of the project was conceived by Heidi Knoblauch who is the Digital Coordinator

of EH. Heidi has worked tirelessly to obtain approval and funding to establish the project.

Ryan Sablosky, the web developer of EH, has setup the backend server which consists of

1. INTRODUCTION 9

the Flask application, Web API and the database. As part of my senior project, I worked

on the mobile application, the front-end templates and views in the backend.

Background

In 2013, Pew Research Center reported that 74% of adults ages 18 and older used their

smartphones to get directions or other information based on their current location [3].

This number which has surely increased over the years as the ownership of smartphones

increases. These statistics are indicative of the immense need and potential in location-

based services through mobile computing.

2.1 Context Awareness

Imagine you enter a departmental store and your smartphone pushes a welcome notiﬁ-

cation and information regarding current deals and discounts. As you pick up an object

on display your phone vibrates and lets you know of the price, the colors available, and

the availability of sizes in the store. Instead of having to ﬁnd an employee and asking

them, your smartphone will provide you with this information. This is an example of a

context-aware system using a mobile application.

A formal deﬁnition of Context-aware computing is deﬁned by Gartner IT as “a style of

computing in which situational and environmental context about people, places and things

2. BACKGROUND 11

is used to anticipate immediate needs and proactively oﬀer enriched, situation-aware and

usable content, functions and experiences.” [4]

Some important aspects of context that are used in these systems are based on [6]:

• Identity (Who)

• Activity (What)

• Time (When)

• Location (Where)

In this paper we will focus on using location as context which in its broader sense is not

just limited to the geographical location but also the objects that build up the surrounding

environment. Mobile applications which are context aware can discover nearby objects

and take advantage of this contextual information. Such applications can anticipate the

potential needs of the user and act accordingly in advance thus providing the user real-time

information when and where they need it without having to manually search for it.

2.2 Location Systems

Currently, there is no standard technology which is used for providing accurate location

indoors and outdoors, and many various techniques and solutions have been proposed.

The most popular technique is to use Global Navigation Satellite Systems (GNSS). GNSS

are systems of satellites that are used to pinpoint the geographic location of a user’s

receiver anywhere in the world. Using information from a number of satellites the system

can triangulate the location of the user to a precision of a few meters [7]. There are

currently two operational GNSS: The United States’ Global Positioning System (GPS)

and Russia’s Global Orbiting Navigation Satellite System (GLONASS). There are also two

2. BACKGROUND 12

GNSS under development: China’s BeiDou Navigation Satellite System and the European

Union’s Galileo [8].

Perhaps, the most widely used GNSS is the GPS. The United States Department of

Defense created the system initially for military use in 1978. Later, it was made fully

operational for all civilians to use in 1995 [8]. Since then GPS has made a signiﬁcant

impact on our lives. It has led to the development of hundreds of applications in several

domains such as transportation, construction, farming, mining and many others.

However, there are a few challenges with GPS when it comes to using it as a sensitive

location context provider. GPS provides location to a precision of 5 meters [8] and therefore

it can be used to pinpoint a user at a neighborhood block but it can not deﬁnitively be

used to tell if the user is in a particular aisle in a store or standing near a particular object.

Another drawback of GPS is that its accuracy can be aﬀected by obstacles in its signal

path such as atmospheric conditions, buildings and trees [9]. Therefore GPS does not work

accurately as a reliable positioning system in indoor and underground locations. Lastly,

since GPS requires communication with several satellites it can be a huge battery drain on

devices such as smartphones [9]. Hence GPS is not a feasible system when a smartphone

needs to constantly monitor location to provide services to it’s users.

Besides using systems that rely on satellites for navigation, companies have done ex-

tensive research on creating alternatives that are more sensitive than GNSS and can also

work indoors.

Perhaps the ﬁrst location system was developed by AT&T Cambridge in the 1990s

called the Active Badge location system. It is an indoor location system that serves to

locate individuals and/or objects within a building by determining the location of the

active badges on them. These badges emit infrared carrying a globally unique identiﬁer

every 10 seconds. These signals are detected by IR sensors around the room and sent to a

central server using a network which in turn provides the location information. The system

2. BACKGROUND 13

was a signiﬁcant ﬁrst step however it had problems due to the usage of infrared. Infrared

detection requires the emission to be within the line of sight thus the positioning of the

sensors is very important and can easily be obstructed by moving objects. Infrared from

the sun and ﬂuorescent lights also interfere with the infrared emitted from the badges and

thus cause inaccuracies in the system. Also, the set up and maintenance of the system is

costly and require several badges, sensors and a strong network which prevents the system

to be employed in larger rooms [10].

Another system called Active Bat location system employed similar techniques as above

utilizing ultrasounds. AT&T researchers in 1999 employed the techniques used by bats in

dark caves to locate objects. Users and objects carry Active Bat tags which emit a unique

ID via ultrasound. These signals are received by ceiling-mounted receivers which compute

its distance from the Bat. The system can locate these bats to within 9 cm of their true

position for 95 percent of the measurements. However such a system requires a large ceiling

sensor infrastructure and is thus expensive and not scalable to larger areas [11].

These systems are hard to implement mostly due to the need for additional hardware

to detect IR and ultrasound signals and to compute the location. Smartphones do not

come with built-in sensors for these signals and thus systems based on these frequencies

are not feasible for location-aware mobile computing. Therefore we turn to systems that

are based on technologies that are compatible with recent smartphones.

A Microsoft Research group developed RADAR which is a building-wide tracking system

using IEEE 802.11 WaveLAN wireless networking technology. The system includes wireless

devices which emit radio waves and a base station which detects and measures the signal

strength. The base station then uses this data to calculate the location of the wireless

devices within the building. This system has a few advantages over the systems mentioned

above. Since it uses RF the system has a large range and does not require line of sight. It

also utilizes the building’s wireless network to operate thus there is no need for additional

2. BACKGROUND 14

infrastructure. Also smartphones come equipped with the ability to connect to wireless

LAN. However, like any system there are drawbacks to this approach. In order to locate

an object, the object must not only support wireless LAN but also be connected to it thus

limiting the smartphone to indoor settings. Also, RADAR locates objects to a precision

of about 3 meters of their actual position and thus cannot be used as a sensitive location

provider [12].

Since the creation of Bluetooth in 1994 the potential that Bluetooth communication

oﬀers has drastically increased. Bluetooth is a wireless technology standard for exchanging

data over short distances using short-wavelength UHF radio waves [13]. Bluetooth has

played a vital role in helping to make devices wireless and allow fast communication

across several types of electronics. Nowadays, Bluetooth can be found in almost every

mobile device, computer, television and even cars. Bluetooth devices communicate with

each other by becoming paired. A device can be set to be “discoverable” which allows

it to be discovered by other bluetooth-enabled devices. After the devices are paired they

can transmit data to each other. Once the pairing is established it is stored in memory

which allows the devices to be automatically paired in the future when they are near each

other [14].

In 2010, the release of Bluetooth Low Energy (BLE) put Bluetooth technology on the

forefront of technologies to provide context. Compared to older versions of Bluetooth which

could transmit large amounts of data such as music and videos, BLE serves to transmit

small packets of data hence minimizing power consumption. This allows for smaller devices

such as smart watches to utilize BLE and operate on coin-cell batteries [15]. Nowadays

BLE is supported by most mobile and computer operating systems including iOS, Android,

Windows, OS X, Linux, and Windows 8.

In 2013, during the WorldWide Developers Conference, Apple introduced the iBeacon

protocol which uses BLE to transmit an advertising packet. iBeacon is built upon the core

2. BACKGROUND 15

of BLE and serves to standardize the advertising packet transmitted by BLE. Therefore,

all smartphones that detect BLE can also detect iBeacon. The iBeacon advertising packet

consists of:

Field Size Usage

Universally Unique Identiﬁer (UUID) 128 bit distinguishes a Beacon (or a group

of Beacons) from another

Major 16 bit optional number used to distinguish

a subqroup

Minor 16 bit an optional number used to distin-

guish individual Beacons within a

subgroup

Measured Power 8 bit a factory-calibrated constant for the

expected RSSI measured 1 meter

from the Beacon

Table 2.2.1. iBeacon advertising packet

Currently, iBeacon has created a huge buzz in the technology industry and is widely being

used and experimented with. This has led to the development of Beacons which utilize

iBeacon to provide location as context and help develop context-aware applications.

Beacons have gained popularity in serving as a sensitive location provider since it can

provide context to smartphones to a precision of a few centimeters which trumps all pre-

vious solutions mentioned above. Since it does not rely on large supplementary hardware,

Beacons can be easily installed both outdoors and indoors. A comparison of all the solu-

tions mentioned in this section is summarized in Appendix A.

2.3 Beacons

According to Wikipedia, a beacon is an intentionally conspicuous device designed to at-

tract attention to a speciﬁc location [5]. The word is widely associated with images of

lighthouses serving as navigational aids for ships near coastlines.

2. BACKGROUND 16

In the realm of technology, Beacons are small wireless devices which constantly transmit

iBeacon signals at regular intervals. Mobile applications can detect these signals, identify

the beacon by the identiﬁer and trigger a location-based action on the device. Apple

introduced iBeacon protocol but do not manufacture the beacons. The physical beacons

are made by third-party manufacturers such as Estimote, Kontakt, Swirl and several

others.

Mobile Applications detect and interact with Beacons in two main ways: Region Moni-

toring and Ranging. Region Monitoring involves deﬁning a region of one or a set of beacons

using the UUID and/or major and/or minor values of the beacons. Similar to geofencing,

region monitoring enables the application to push notiﬁcations when the smartphone en-

ters or exits the deﬁned region [16]. The unique ability of this interaction is that even if

the application is not running, the application is launched in the background and the noti-

ﬁcation is pushed. An example of its real-world application includes a user being instantly

notiﬁed about the current deals as they enter the store.

While monitoring operates with a region, ranging involves detecting individual signals

and estimating their proximities to the smartphone. It is important to note that iBeacon

provides information about proximity and not exact location; iBeacon can answer what

items are nearby but not where you are. Absolute location is a ﬁxed location deﬁned by

longitudes and latitudes or some form of coordinate system. GPS is a system that provides

absolute location information. However, proximity refers to the distance in relation to

some object (in our case a beacon) and is capable of determining if an object is nearby

but cannot determine where exactly it is [22]. The beneﬁt of proximity is that mobile

applications can identify nearby items of interest which are often independent of location

and may also be mobile. For instance, in a store a user can be notiﬁed when an employee

is near them.

2. BACKGROUND 17

Since most smartphones now support detection of BLE, it can estimate proximity to

the beacon by using the signal strength to calculate Received Signal Strength Indicator

(RSSI). The stronger the signal, the closer the beacon is to the smartphone. Since BLE

does not require the smartphone to pair with the beacon, it can receive signals from

multiple beacons. It infers which beacon is nearest to it by measuring and comparing their

individual RSSI. Using iBeacon and RSSI, smartphones can also approximate the distance

from the beacon. iBeacon signal transmits Measured Power (8 bits) which is a factory-

calibrated read-only constant for the expected RSSI measured 1 meter from the beacon.

Using this constant and the RSSI, an estimate of the distance between the receiver and

the beacon can be calculated [22]. This calculation of the distance can be inaccurate if

there are a lot of obstructions within the room which can dampen the signal strength.

2.4 Current Applications of Beacons

BI Intelligence, tech research, claims that beacon technology is the fastest-growing in-store

technology since mobile credit card readers and predicts installation of 4.5 million active

beacons in the U.S by the end of 2018 [17]. Industries that seek to improve customer

experiences and maintain strong relationships with their clients have started implement-

ing Beacons all over the world. Beacons have been deployed and tested in many sectors

especially retail, entertainment, travel and tourism.

Perhaps the industry that will reap the most beneﬁts (and proﬁts) from using Beacons

is retail. One prime example is Macy’s deployment of 4000 beacons in stores throughout

the U.S during the holiday season in 2014. Using beacons, retailers can send customers no-

tiﬁcations about product speciﬁcations, videos of how to use products, coupons and deals.

Retailers can also use the technology to monitor movements and patterns of costumers

within the store in order to improve product placements and personalize notiﬁcations

based on past purchases [18].

2. BACKGROUND 18

Airports and airlines have also taken up the technology. Virgin Atlantic set up beacons

in the Upper Class Wing at Londons Heathrow Airport in May 2014. They oﬀered a variety

of services including personalized duty-free and currency exchange oﬀers to passengers and

alerting passengers to prepare their boarding passes as they near security check-ins [18].

Japan Airlines also continued the trend in Tokyos Haneda Airport Domestic Terminal 1.

By setting up an indoor positioning system, the airlines staﬀ is equipped with smartphones

allowing the airlines to locate staﬀ members and assign location-speciﬁc tasks to them [18].

American Airlines also deployed a trial run at the Dallas Forth Worth Airport in June

2014 to help passengers navigate the airport by providing them with information about

distances to gates, boarding times and security check lines.

In the sporting world, Major League Baseball (MLB) took up the opportunity to provide

location based advertising as well. In March 2014, it set up beacons in 28 of its 30 ballparks

around the U.S. Through the MLB application, sports fans receive oﬀers for merchandise

coupons, information on concession stands and history of the venue, ability to check-in

and even video clips of game replays. MLB reported that the number of check-ins tripled

from 2014 to 2015 and that it is looking for ways to add to the application to further

enrich the experience of the fans [18].

Starwood Hotels & Resorts is running beacons in 30 of its hotels and resorts. The

beacons are helping the concierges in greeting guests by name and accelerating the check-

in process for frequent guests. It has also implemented a pilot program that will allow

Starwood guests at two of their U.S. hotels to skip the check-in process and along with a

partner application unlock their room door using their smartphones [18].

After being popularized by Apple and big brands, local businesses and institutions have

also started using Beacon technology to aid in their services. Craft brewery Schlaﬂy Beer, a

bar in St. Louis, MO, is utilizing beacon technology to better connect with their customers.

Beacons are located on beer taps to push information about drink specials and new beer

2. BACKGROUND 19

releases to engage with customers at the key moment when they are about to order a

drink [19]. In Bucharest, Romania, public transport is employing beacon technology to

make the city more accessible for visually impaired citizens. Instead of having to rely on a

friend for help, visually impaired citizens, using a mobile application, can now be notiﬁed

by voice output when their bus pulls up and be directed to it through the station [20].

Beacons have also become popular in providing engaging experiences to visitors by acting

as a virtual tour guide. In the famous Antwerp museum in Belgium, visitors are directed

towards exhibits and notiﬁed about stories behind the exhibits. The beacons also stimulate

interaction with visitors through interactive trivia questions [21].

It is clear with the increase in usage and applications around the world that beacon

technology is a powerful tool in helping provide location as a context. Beacons are not

only limited to promoting advertisements but can also serve to deliver valuable information

to people on a daily basis.

2.5 Challenges with Beacons

Like any emerging technology, Beacons have drawbacks:

The main challenge of working with Beacons is the interference in signals due to ob-

structions in the area which can signiﬁcantly aﬀect the range of the beacons. Therefore,

positioning of the beacons is important and they should preferably be placed on ceilings

or on walls at a height higher than that of an average adult.

Another issue that has arisen is regarding the security issues with Beacons. Although

beacons do not transmit any sensitive information, they do however transmit their iden-

tiﬁer without any encryption. These identiﬁers can be detected by any smartphone and

used by a competitor or malicious group in their applications. For instance in a store a

user can receive notiﬁcations about better deals from a rival store simply because the rival

2. BACKGROUND 20

store piggybacks on the beacon network set up in the store. For this case to happen the

user needs to have the application from the rival store installed [24].

In large spaces a considerable number of beacons are required to ensure continuous

coverage. Conversely, in small spaces overlapping of beacons can be a problem especially

if signal strengths are similar causing the mobile application to continuously toggle between

the beacons [23].

On the mobile side, if the application requires fetching data from a server then Internet

capabilities must be available which may not always be the case in the outdoors. Also,

constant use of cellular data or Wi-Fi can quickly diminish battery life which serves to be

counter-intuitive as BLE is preferred for its low energy consumption.

Since beacons are small physical devices that are usually attached to walls and objects,

it is very easy for them to get stolen or vandalized [23].

Although beacons operate on BLE which enables the small devices to last for a long

time, the batteries do run out eventually and require manual replacement which can be

very timely and expensive depending on the number of beacons deployed.

2.6 Debunking the Myths

Similar to the advent of most new technologies, iBeacon has met with hesitation and

reluctance which results from the lack of knowledge among people regarding the technol-

ogy. The main concern consumers have is that Beacons track their locations and access

their private information without their consent. In fact, Beacons simply transmit a unique

identiﬁer which is detected by a smartphone and causes mobile applications to react ac-

cordingly. Beacons do not receive data and thus do not contain any data about the users.

Any malicious act such as tracking a customer’s location and habits is done by the mobile

application. There are several steps that the user undertakes to grant mobile applications

consent to perform such acts. A user has to download the mobile application, accept the

2. BACKGROUND 21

terms and services agreement and activate their Bluetooth [29]. Thus Beacons themselves

do not pose any threat to the user’s privacy. The mobile application can but the user has

complete control whether they consent to such acts or not. At any time they can reverse

the decision by deleting the application or turning their Bluetooth oﬀ.

2.7 Alternative to iBeacon

Other companies have taken up a similar venture as Apple and created their versions of

BLE standards as alternatives to iBeacon. Currently, the main competitor is Eddystone

which was launched by Google in 2015. The main beneﬁt of using Eddystone over iBeacon

is that it has added to the iBeacon speciﬁcation. One main diﬀerence is that Eddys-

tone contains an additional identiﬁer called Eddystone-URL which, as the name suggests,

transmits a URL which opens up on the smartphone’s built-in web browser and thus

the smartphone does not require a mobile application [24]. Since Eddystone is relatively

new, there are not many manufacturers who are producing Beacons with the Eddystone

speciﬁcation. Although Eddystone has been released, Google is still working on improving

Eddystone and adding more identiﬁers that can be used for diﬀerent purposes. Hence,

iBeacon continues to be the popular speciﬁcation used to manufacture Beacons and these

iBeacon-based beacons are being used in several running applications and projects.

Project Requirements

3.1 Deﬁnitions

• Beacons: Beacons that provide context to smartphones

• Item: A document containing text, image and/or video

• Project: Based on a topic, a project consists of one-on-one associations between a

set of beacons and items

• Users: Users create and maintain projects on the web application

• Participant: A person who downloads the mobile application and enters an instal-

lation

• Installation: An exhibition set up in a physical space by users using beacons to

provide participants location-speciﬁc information.

3.2 Use Case Diagrams

To clearly illustrate the requirements and models of a system, Use Case Diagrams are

used. Use Case Diagrams consist of Actors which represent external agents and Use Cases

3. PROJECT REQUIREMENTS 23

which represent the actions or sequence of actions that the Actors can take. In our project

there are two external agents: Users and Participants.

1. Users:

Users manage projects and content by using the web application. Users can have

three roles: Admin, curator and collector. These roles diﬀer in terms of access and

permission to the projects and its contents. The roles and their respective permissible

actions are shown in Figure 3.2.1.

Figure 3.2.1. Use Case Diagram for Web Application

• Admin, labeled in red, has the most control. Admin can create new projects,

add curators and collectors, assign users roles and permissions to projects,

change the roles a user has, and manage the project in every way.

3. PROJECT REQUIREMENTS 24

• Curators, labeled in yellow, have the second most control. Curators can man-

age the projects that they are authorized for, however, can not create projects

or edit user roles.

• Collectors, labeled in blue, have the least control. Collectors can only manage

items for projects that they are authorized for.

The users set up the physical installation by placing Beacons on walls and objects

based on the items they have associated with the Beacons in the web application.

2. Participants:

Participants interact with the physical installation by using their mobile application.

They move within the installation and based on their proximity to a Beacon the

mobile application displays the associated item.

Figure 3.2.2. Use Case Diagram for Mobile Application

In both the Use Case Diagrams there is an external data source which is used to store

and retrieve data. With these diagrams, we have established the Actors in our system and

the requirements that our system should provide the Actors. In the next chapter we design

the architecture of the system that will accomplish these requirements.

System Design

The architecture of this system is designed on a client-server model. The client-server

model is a distributed application structure that partitions tasks between the providers

of a service, called servers, and those who request the services, called clients [25]. Client-

server model helps divide the diﬀerent processes in the application to optimize work done

at the client and server side. It also reduces redundancy since the data is stored on the

server instead of each client.

There are two main types of architecture systems based on this model: 2-tier and 3-tier.

The 2-tier architecture involves only a client and a database server as seen in Figure 4.0.1.

In this architecture, clients are called thick because they hold all the application logic and

directly connect to the database to retrieve information without involving any intermediary

structure. The main disadvantage with the 2-tier approach is diﬃculty in scalability and

upgrades [26]. Therefore most systems now implement a 3-tier architecture.

In a three-tier architecture the software is divided into 3 diﬀerent tiers: Presentation tier,

Application tier, and Data tier (Figure 4.0.2). The client is part of the presentation tier

which contains presentation logic and provides user interfaces. The Application tier which

4. SYSTEM DESIGN 26

Figure 4.0.1. 2-Tier Architecture

Figure 4.0.2. 3-Tier Architecture

holds most of the application logic serves as the intermediary between the Presentation and

Data tiers. The Data tier is the database server that stores and retrieves data. Since the

presentation tier holds little application logic it serves to get user inputs and send requests

to the application tier, and receive responses from the application tier and accordingly

update the interfaces. The application tier processes requests and in turn calls on the data

4. SYSTEM DESIGN 27

tier to provide it with the required data [26], and it processes said data and sends the

response back to the client. The advantage of a 3-tier architecture is that the modularity

increases scalability and ﬂexibility by allowing upgrades and replacements to be done

independent of other components.

Figure 4.0.3. Initial System Design

Our project employs a 3-tier client-server architecture system as shown in Figure 4.0.3.

The presentation tier includes the mobile application that the participants download and

use to interact with the installation, and web browsers which render the web application

that users use for content management. The application tier holds the application logic

and receives requests from clients and responds accordingly by pushing to and pulling

4. SYSTEM DESIGN 28

from the data tier. The Data tier comprises of the database which stores information

about users, projects, beacons, items and the associations between beacons and items.

Technical Implementation

In this chapter we expand our initial system design and add technical details to each tier

which includes the technologies used and speciﬁc ﬁle names in our project. The modiﬁed

design is shown in Figure 5.0.1.

The chapter is divided into sections which elaborate each tier, its respective components,

application development environments and relevant technical code.

5.1 Estimote Beacons

There are currently several third party companies that manufacture Beacons based on

Apple’s iBeacon protocol. There are a few factors that need to be considered when decid-

ing which Beacon to purchase and use in the project. Perhaps two of the most important

factors are the battery life and the companies’ supporting software for Beacon manage-

ment. Estimote is by far the most popular company in the market currently. Using coin

size battery Estimote promises upto three years of battery life. Estimote also provides a

Beacon management system where users can view their Beacon settings such as battery

life and edit the iBeacon advertising packet such as major and minor values. Because of

5. TECHNICAL IMPLEMENTATION 30

Figure 5.0.1. Final System Design

these reasons we decided to purchase Estimote Beacons and use them in the project. I

worked with a starter development kit of 3 Estimote Beacons.

5.2 Data Tier

The database used is SQLite which is a relational database management system. SQLite

provides high performance and simplicity since the entire database consists of a single

ﬁle making it great for testing and development purposes. The database is managed and

tested using DB Browser for SQLite which is an open source tool and provides simple

visuals to view and edit the database.

Appendix B shows the schema of the database. The tables are organized and related in

a manner to reduce redundancy and simplify querying across multiple tables. There are

5. TECHNICAL IMPLEMENTATION 31

several many-to-many relationships in the database for instance from projects to items

where many projects can share relationships to many items. The same holds for projects to

beacons and projects to users, thus, there are through-tables to store these many-to-many

relationships.

• User: stores all the users registered in the system along with their personal infor-

mation. The primary key is the ID ﬁeld which is used to reference users in other

tables.

• Role: stores all the possible roles of the users- Admin, curators and collectors.

• UserRoles: stores all the users along with their respective roles.

• Project: stores all the projects along with its information. The primary key is the

ID ﬁeld which is used to reference projects in other tables.

• Beacon: stores all the Beacons along with their iBeacon ﬁelds (UUID, Major, Mi-

nor). The primary key is the ID ﬁeld which is the unique Beacon ID and is used to

reference Beacons in other tables.

• Item: stores all the items along with their information. The primary key is the ID

ﬁeld which is used to reference items in other tables.

• BeaconItemMap: stores all the associations between beacons and items along with

their respective projects.

• Project

User Through: tracks many-to-many relationships between projects and

users.

• Project Beacon Through: tracks many-to-many relationships between projects

and beacons.

5. TECHNICAL IMPLEMENTATION 32

• Project Item Through: tracks many-to-many relationships between projects and

items.

5.3 Application Tier

The application tier consists of the Flask web application which is rendered on the web

browser client and is used by users to manage projects, and the Web API which pub-

lishes RESTful services containing data from the database which is fetched by the mobile

application client to display content.

5.3.1 Web Application

The web application is built using Flask. Flask is a micro web framework written in Python

based on Jinja2 template engine. Flask serves to keep the web application development

simple and extensible [27]. Flask supports the addition of several extensions which add

extra functionality to the application. Jinja2 is the default templating language for Flask.

Jinja2 serves to combine a template written in HTML and CSS with logic and data

structures to render dynamic web pages.

The web application is deployed and tested locally on the computer using Virtualenv.

Virtualenv is a useful tool that creates isolated Python development environments. The

application code is written and managed using Microsoft Visual Studio which provides a

powerful editor for both python and HTML ﬁles.

Flask, like most other web frameworks, employs the Model-View-Controller (MVC)

architectural pattern to modularize code by separating the data model (models.py), ap-

plication logic (views.py) and user interface (templates folder) [28].

5.3.1.1 Models.py

In large projects with complex database schema querying the database using SQL be-

comes tedious thus using Object-relational mappers (ORM) is preferred. ORM maps data

5. TECHNICAL IMPLEMENTATION 33

stored in relational database tables into objects. Usage of ORM leads to huge reduction in

code and allows developers to extend object oriented programming to dealing with data

from databases as well. The main beneﬁt of ORMs is that by mapping relational tables to

classes, developers can refer to objects of the classes and their ﬁelds throughout the ap-

plication without having to query SQL CRUD (Create, Read, Update, Delete) logic each

time. The ORM used in the project is Peewee which is a simple and easy to use ORM.

Flask-Peewee is a Flask extension that adds support for Peewee to the Flask application.

The ﬁle models.py establishes connection to the database and deﬁnes model classes.

Model classes map to relational tables in the database, ﬁelds (or attributes) map to

columns in a table and therefore an object refers to a row in a table. For example the

Project table in the database is mapped to:

Due to this class deﬁnition, an instance of the Project model class can be used to refer

to a particular project from the database and its attributes like name and description can

be obtained in the same manner as in object-oriented programming:

Any modiﬁcations to the objects and their ﬁelds throughout the application are reﬂected

in the database thus Models.py serves to connect to and manage data in the database using

the Peewee ORM.

5. TECHNICAL IMPLEMENTATION 34

5.3.1.2 Views.py

Views.py contains controller methods which are associated to a route. When the user

enters a URL, the application matches the URL with the predeﬁned routes and runs

the associated controller method. Within the controller method, if necessary, the model

classess are used to retrieve data from the database. The data is stored in a structure for

instance a list or a dictionary and then passed to a view which renders the HTML page.

The image above shows the proﬁle controller which is run when the user types or is

directed to the /proﬁle URL. It accesses the Project class shown in section 5.3.1.1 and

retrieves all the objects in a list. It then passes the list to the proﬁle.html template which

is then rendered and displayed on the web browser client.

5.3.1.3 Templates Folder

The templates folder contains all the HTML web pages which are rendered along with data

structures passed by the controller methods using Jinja2. The main beneﬁt of using Jinja2

templates is that the template can contain variables, statements and logic expressions

which are evaluated and replaced with corresponding values when the page is rendered.

Statements and logic expressions such as if statements and for loops are placed within {%

%}, and variables are placed within {{ }}. We continue with the example above of the

proﬁle controller that passes a list named projects to the proﬁle.html template.

5. TECHNICAL IMPLEMENTATION 35

The image above shows a portion of the proﬁle.html where a for loop iterates over all

the projects and enters the name and description ﬁelds of each project into a table.

Another beneﬁt of using Jinja2 is using inheritance within templates. Instead of reusing

existing code in diﬀerent templates (for example header and footer) templates can inherit

other templates. proﬁle.html inherits the layout2.html template. In order to do so textit-

layout2.html must specify a labeled block that can be overwritten by other templates:

proﬁle.html must include:

and the labeled block content:

Similarly, there can be several blocks placed within a template that can be overridden by

another template that inherits it for example blocks to specify the title, content, caption

etc for the web page.

In templates, static ﬁles for CSS and JavaScript are also required. The standard ap-

proach is to create a static folder which contains all style sheets and other static content

that the templates may require. Referencing these ﬁles in the templates is achieved by

using the Flask url for which generates a URL for the static ﬁle as seen in the image

below.

5. TECHNICAL IMPLEMENTATION 36

5.3.1.4 Flask-Security

Flask-Security is an extension that adds security mechanisms like user authentication,

authorization, registration and password recovery to a Flask application. It is also used

to track the current user, their login activity and their respective role.

Flask-security is a very powerful tool that handles most of the authentication for the

developers. It provides a module named current user which can be accessed in templates

and python ﬁles. It refers to the current user who is logged in and is an object of the

User model class in models.py. Therefore, the ﬁelds of the current user can be retrieved

in the same object oriented manner as described in section 5.3.1.1. Unlike other objects

current

user is a global variable throughout the project and does not need to be passed

to templates. Hence, rending user speciﬁc information on web pages become simple. For

example, if the current user is logged in then the webpage will show their email and the

option to Logout, otherwise it will show the option to Login.

Flask-Security also keeps track of the role of the current user and thus this can be used

in templates to display certain parts of webpages to users depending on their roles and

privileges. For example, only an admin is able to view the Add Project link.

5. TECHNICAL IMPLEMENTATION 37

In views.py, we can restrict users access to a given webpage by using decorators on

controller methods that render the webpages:

• @login required: ensures that if the current user is not logged in then they cannot

access the web page rendered by the controller’s route.

• @roles required(“admin”): ensures that if the role of the current user is not admin

then they cannot access the web page rendered by the controller’s route. Similarly @

roles required can be used for curators and collectors depending on their privileges.

5.3.1.5 Flask-WTF

Forms are an important part of user interfaces in web applications. In this project, forms

are used by users to manage content like create and edit projects, items and beacons.

WTForms is a python library which provides ﬂexible form rendering and validation. Flask-

WTF is a Flask extension that extends the functionality of WTForms into the project.

WTForms in a Flask application employs a similar MVC approach as discussed before

for rendering. Forms.py is a python ﬁle which creates classes for each unique form. Each

form class contains class variables which represent form ﬁelds. The image below shows

an example of a UserPrefs class which represents a form that is used by users to edit

their personal settings. These settings are represented by the class variables like name and

occupation.

5. TECHNICAL IMPLEMENTATION 38

In views.py, the controllers can, instantiate a form object, just like models, and pass it to

the template to be rendered by the view. Another useful aspect of using WTForms is form

validation and submission which is handled easily and reduces the amount of boilerplate

code a developer needs to write. As shown in the image below initially the form object of

the UserPrefs class is instantiated. If the form is for editing, like in the image, then the

form ﬁelds are loaded with preexisting stored values. Therefore when the form is rendered

it displays the current values of the variables. When the user submits a form, it is validated

and the values of the ﬁelds are stored. In the image, it is stored with the current user,

however, in other forms it is stored in the objects of the model classes in consideration.

Unlike rendering a template, after a form submission the controller method redirects to

another controller method in views.py. In the image the controller redirects to the URL of

the proﬁle controller which in turn renders the proﬁle.html template displaying the edited

values.

5. TECHNICAL IMPLEMENTATION 39

In the template, we continue to use the HTML form tag however the ﬁelds are repre-

sented by the variables of the form object passed to the template.

5. TECHNICAL IMPLEMENTATION 40

A key point to note in controller methods is that the route defaults to GET requests

meaning that the browser has access to GET information from the server and the controller

method thus provides that information. However, in the example of form submission the

controller method needs to explicitly contain the methods allowed in the route:

This permits the browser to POST requests to the server and update the information

stored.

5.3.1.6 Summary

The MVC architecture described in this chapter serves to render dynamic templates for

all controller methods and HTML ﬁles in the project. Appendix C lists all the HTML ﬁles

along with their respective views and roles within the project. Appendix D illustrates the

templates rendered on the web browser showing from top to bottom the sequence of web

pages that leads the user from their proﬁle to the dashboard where they can manage the

project, beacons and items.

5.3.2 Web API

The application tier also consists of a Web API which uses representational state transfer

(REST) to communicate data between diﬀerent components over the World Wide Web.

Currently, REST is the standard for publishing web services and web APIs mostly due

5. TECHNICAL IMPLEMENTATION 41

to its simplicity and stateless architecture. Clients can request resources simply by using

the resource identiﬁer (URI) without any knowledge of the state of the resource or its

origin. RESTful APIs do not require a speciﬁc format for the data however the most

popular format is JSON. In our project RESTful API publishes information about projects

and, beacon and item associations in JSON format. The main advantage of formatting

the response in JSON format is that it is lightweight and can be processed by most

programming languages and thus our system can be expanded to incorporate other clients

such as iOS devices.

Flask, using a similar MVC approach as before, is used to publish RESTful Web APIs

as well. The Web API primarily serves to respond to the requests sent by the mobile

application on the deﬁned URLs. The controller methods in the API have deﬁned URLs

which publish JSON data. The image below shows an example of a controller that publishes

all the projects in the system.

The controller uses the Project model class to obtain all of the projects in the system

and enters the projects along with certain ﬁelds into a JSON object.

This JSON object is then published on the server as shown below:

5. TECHNICAL IMPLEMENTATION 42

Similarly, another controller method which is used to respond to requests from the

mobile application is project beacon. It responds to the request by publishing a JSON

object containing information about the item associated with the Beacon id sent as a

parameter in the URL.

5. TECHNICAL IMPLEMENTATION 43

The controller method, as shown in the image above, retrieves the associated item

by using the Item, BeaconItemMap and Beacon model classes. This example shows how

the Peewee ORM simpliﬁes querying across multiple tables. The JSON object containing

information about the item is published onto the server as the response.

5.4 Presentation Tier

The mobile application is built for Android devices using Android Studio which is the

oﬃcial integrated development environment (IDE) for Android platform development.

The application is deployed and tested on the Google Nexus 7 tablet.

The mobile application serves two main purposes:

1) Detecting and interacting with Beacons using Ranging and Monitoring.

2) Sending HTML requests to access resources available on the server using URLs

constructed dynamically within the mobile application.

5.4.1 Beacon Ranging and Monitoring

Estimote has a powerful SDK for Android which provides the necessary modules to interact

with Estimote Beacons. From the SDK we need to import BeaconManager which handles

5. TECHNICAL IMPLEMENTATION 44

all interactions with Beacons, Region which is used to deﬁne a region of Beacons using

Beacon IDs, and Beacon which represents a single Estimote Beacon.

As mentioned before, Beacon monitoring is used to notify the mobile device when it

enters or exits a region of Beacons. One of the key features of Beacon Monitoring is that

it functions even when the application is running in the background. BeaconManager pro-

vides built-in methods that aid in monitoring with beacons as seen in the image below:

1. startMonitoring and stopMonitoring serve to schedule monitoring. startMonitoring

is always running which allows the application to constantly scan for Beacons in the

background. stopMonitoring is only used when the battery of the mobile device is

in consideration. In this example, the region is deﬁned using the UUID which is the

same for all of our purchased Beacons. In real-life installations the region will be

deﬁned by those beacons that are present near the entry and the exits.

5. TECHNICAL IMPLEMENTATION 45

2. setMonitoringListener scans for Beacons in the area which are included the prede-

ﬁned region

3. The Listener passes the event to one of the following methods: onEnteredRegion or

onExitedRegion which pushes a notiﬁcation to the mobile device.

onEnteredRegion pushes the notiﬁcation as shown below:

onExitedRegion pushes the notiﬁcation as shown below:

Beacon ranging involves identifying individual Beacons and their proximities to the

mobile device. Similar to Monitoring, BeaconManager provides setRangingListener which

identiﬁes Beacons within a predeﬁned region and returns a list of Beacons ordered by

decreasing RSSI values. From that list, the ﬁrst element is selected since that represents

the nearest Beacon to the mobile device. From the nearestBeacon, the unique Beacon ID

is obtained which is then used to construct a URL to communicate with the server to

obtain the associated item.

As the participant moves around the installation, the mobile application constantly

calculates the nearest beacon and according to that fetches data from the server. Estimote

5. TECHNICAL IMPLEMENTATION 46

SDK hides most of the technical details for example calculating RSSI values and scanning

Beacons within a region, therefore, providing developers an easy approach to interact with

Estimote Beacons.

5.4.2 GET requests to server

With Android devices, the current approach to send HTTP requests over the network is via

using Volley. Volley is an HTTP library that integrates easily with RESTful APIs and is

compatible with data in JSON format. It primarily functions by creating a RequestQueue

and passing Request objects to a given URL. Volley provides built-in support for sending

requests and therefore reduces large chunk of boilerplate code and allows developers to

write more application-speciﬁc code.

In our mobile application, only GET requests are sent to the server. Currently, the

system only permits the mobile application to GET information from the server and not

POST, DELETE or UPDATE.

With the current implementation of the mobile application, the ProjectActivity presents

all the projects in the system to the participant to select from. In sendRequestForProjects

a GET request is sent to the URL PROJECTS. The URL PROJECTS is a ﬁxed variable

and does not need to be dynamically altered during the application.

After the server receives these requests, it matches the given URL with the deﬁned

routes of the controllers and executes the list projects controller as shown in section 5.3.2.

On the mobile side, after the request is made if the response is received successfully in

JSON format then the onResponse method is called, otherwise the onErrorResponse is

called. In onResponse the JSON object is parsed and the information is entered into an

Android ListView widget.

5. TECHNICAL IMPLEMENTATION 47

The List View presents all the projects to the participant who then selects the project

they are interested in as shown in the image below:

5. TECHNICAL IMPLEMENTATION 48

5. TECHNICAL IMPLEMENTATION 49

After the participant selects a project, an intent is created to the MainActivity along

with the project id.

In the MainActivity, the application begins Beacon ranging. Beacon ranging constructs

a URL ITEM dynamically containing the project id that the user selected and the id of

the beacon nearest to the mobile device.

In sendRequestForItem, the URL ITEM is used to send a request to the server to obtain

the JSON object which contains information about the item associated with the nearest

beacon in the current project. The server matches the URL ITEM with the routes of the

controller methods and executes the project beacon method shown in section 5.3.2.

After the JSON object is parsed, the html of the item is extracted and it is displayed

by the application using an Android WebView widget as shown in the diagram below:

5. TECHNICAL IMPLEMENTATION 50

5. TECHNICAL IMPLEMENTATION 51

5.4.3 Overview

The class diagram for the mobile application is illustrated below:

Class Purpose

SplashActivity Temporary page at the beginning of the application which displays a

short overview and purpose of the application

ProjectActivity Gets projects from server and allows participants to select a project and

begin their tour

Project Project class used to instantiate Project objects in ProjectActivity

MainActivity Displays associated item of nearest beacon from the project selected by

the participant

Monitoring Runs on the UI thread and pushes notiﬁcations when user enters/exits

the beacon’s range (even when the application runs in the background)

Table 5.4.1. Purpose of each Mobile Application class

Results

The project successfully incorporates the system design mentioned earlier. The web ap-

plication allows management of projects, beacons and items and the data is stored within

the database. The mobile application sends requests to the server, receives the required

data and displays it.

6.1 Testing

The date for the exhibition on Mass Incarceration is September 2016. For this project, I

worked with three beacons and developed the web application locally on my computer.

Therefore, the applications were tested locally and not on a larger scale.

The key components that were monitored and tested include:

1. Database Storage: It is important that the data entered by the users in the web

application is stored correctly in the database. Using the DB Browser for SQLite I

was able to verify that the data was indeed being stored in the correct tables and in

the correct format.

6. RESULTS 53

2. GET Requests to server: The Web API publishes services on the local server

and therefore the mobile application on the tablet is not able to send requests to

the local server bound on my physical computer. I used www.myjson.com which is

a free hosting service to publish the JSON responses on the internet. In my mobile

application I hard coded the URLs from myjson.com to test whether my mobile

application was able to GET data from a server, parse the JSON object and output

the correct values.

3. Beacon ranging: By viewing the BeaconItemMap table in the database I am able

to verify that the item displayed by the mobile application was indeed the one

associated with the nearest beacon.

6.2 Evaluation

The evaluation requirements of the web application set by the client (EH) are included in

the Appendix E. After viewing my progress the client has decided to move forward with

the project without my contributions.

There were a couple of aspects of my contribution that the client were unsatisﬁed with:

• JavaScript in the front end templates

• Absence of Map View, User Admin Page and Item ﬁltering

• Edits of the backend particularly the views.py ﬁle which interferes with other backend

code written by Ryan.

• Less changes in the templates

• Glitches in the project that cause it to crash

As I reﬂect on the feedback that was given to me by the client, I understand the ways in

which I could have worked diﬀerently to produce the product that they wanted. Since, I

6. RESULTS 54

am the ﬁrst computer science senior that has worked on implementing a technical project

with a client, I will discuss the changes that I would make if I had the opportunity to

recreate this project and hopefully these changes can be used in the future with seniors

that will complete similar projects.

The ﬁrst change would be on the communication front of my interaction with the client.

There was miscommunication about the project layout and the expectations on both mine

and the client’s end. Weekly meetings and check-ins with both the clients and my advisor

together would have helped decrease these misunderstandings.

I would also ask the client to make the requirements document more clear and explicit,

especially with the layout and sequence of pages as this was left open for my interpretation.

Ideally, I would have preferred an overview of the project, the setup, the diﬀerent variables

used and detailed write-up of the individual components that I had to implement.

This has been a great learning experience that I am grateful for both academically

and in terms of teamwork skills. I have learned that collaboration on software projects is

diﬃcult since we are each contributing portions of a code into a larger project and we all

have diﬀerent approaches to coding.

As a student, I have enjoyed learning and understanding the overarching architecture

and the diﬀerent technologies used in the project. I desired to understand the underlying

concepts behind the diﬀerent components in the project and that is why I spent time

researching and understanding those concepts.

Conclusion

Estimote’s Steve Cheney : “The online world that we are used to has tons of available

information but the physical world is this place we are trying to navigate at all times, and

your phone does not have any context about it. Beacons are one way to solve that.” [30]

The Beacon technology is a great improvement on the past solutions that have aimed

to provide location as context. Beacons are small, cheap and do not require additional

hardware. Most companies that produce Beacons provide a supporting management sys-

tem which can be used to modify Beacon settings. In section 2.4 we discussed the current

implementations of projects using Beacons around the world. The main market for Bea-

cons is surely advertising and marketing. However, its potential has been extended to

other ﬁelds as well for instance in museums and small businesses. This is indicative of the

widespread beneﬁts of Beacons to serve users in providing location-based services. There

are deﬁnitely drawbacks in using Beacons (loss of signal strength) however the poten-

tial it possesses only seems to grow. The technology is constantly being improved upon

and integrated with existing technologies to satisfy the need of the consumers to receive

information when and where they need it.

7. CONCLUSION 56

7.1 Limitations of the system

During testing I realized that since Beacons broadcast signals every 10ms the mobile

application continuously receives the signal and sends a GET request. This causes the

content to be loaded continuously. Based on the installation and need for content update,

the broadcasting interval needs to be changed in the Estimote Beacon management system.

Another concern is the range of Beacons. Beacons general have long ranges which depends

on both the deﬁned signal strength and the battery power of the Beacon. These factors

can cause Beacons of varying proximities to have similar RSSI values causing inaccuracies

in the application. Especially if the Beacons are close to each other the mobile application

can ﬂuctuate between several nearest Beacons. Therefore when setting up the installation

Beacon ranges, battery levels and broadcasting intervals need to be monitored, tested and

accordingly changed in the Estimote Beacon management to provide the best possible

experience to the participants.

The mobile application requires the availability of Internet to deliver data to the par-

ticipants. Therefore, this project requires not just Beacons but also availability of Wi-Fi

or cellular data. Also, fetching data from the server continuously can have a signiﬁcant

eﬀect on the battery of the mobile device.

7.2 Future Work

Currently, the web application successfully creates a project and can be used to manage

its contents. However, more functionalities need to be added and glitches in the system

need to be handled. On the mobile side, the concerns listed above need to be addressed

as well.

There is currently research being done on creating location-aware systems that incorpo-

rate both Wi-Fi and Beacons. Meraki, a division of Cisco, is working on producing access

7. CONCLUSION 57

points that incorporate Wi-Fi and Beacon technology [31]. These access points can serve

as regular Beacons which transmit iBeacon advertising packets and interact with mobile

applications. These access points also serve as routers allowing consumers to connect with

the internet. Therefore instead of having separate hardware for both technologies Meraki

is aiming at an integrated access point that can serve as a router and as a beacon in order

to provide faster and more eﬃcient location-based services.

Appendices

Appendix A

Comparison of Location Systems

APPENDIX A. COMPARISON OF LOCATION SYSTEMS 60

Appendix B

Database Schema

APPENDIX B. DATABASE SCHEMA 62

Appendix C

Table showing all the HTML ﬁles and respective

controller methods in views.py

APPENDIX C. TABLE SHOWING ALL THE HTML FILES AND RESPECTIVE CONTROLLER METHODS IN VIEWS.PY64

Appendix D

Images of Web application rendered on browser

APPENDIX D. IMAGES OF WEB APPLICATION RENDERED ON BROWSER 66

APPENDIX D. IMAGES OF WEB APPLICATION RENDERED ON BROWSER 67

Appendix E

Web Application Requirements Document

APPENDIX E. WEB APPLICATION REQUIREMENTS DOCUMENT 69

Objective criteria

● Responsive -- it must scale smoothly to screens of varying size, from a big-screen TV to

a smartphone.

● Enhances progressively -- the design should be functional on approximately 95% of

browsers. Key, basic, functionality should not rely on JS (or should have a non-JS

fallback that kicks in automatically).

● Low-latency -- to the extent technically possible no aspect of the frontend should

introduce an undue lag on the user’s experience.

● Accessible -- to the extent practical, usable by people not using a traditional web

browser/keyboard/mouse combo. (ARIA compliant)

● Integrated with the rest of the project -- both code and (open-source) licensing

● Semantic markup -- where applicable, takes advantage of more modern, semantic tags

like <author>, <article>, etc. as well as metadata

● Valid -- the resulting markup pushed to a browser should pass a modern HTML validator

check (https://validator.w3.org/ and/or https://validator.nu) with few-to-no warnings and

no errors.

Subjective criteria

● Not ugly -- should look nice.

● Reasonably interactive -- the user should get feedback for their actions -- but not too

much.

○ Small animation on a vital notification to grab a user’s attention: good.

○ Having a lightbox pop-over notification that swings to-and-fro to let the user know

that they’ve added an item to the database: bad.

● Lightweight -- should not download 15Mb from some CDN just so you can get a

particular fade or font.

● Intuitive UX -- in an ideal world, this project will be used by people of diverse levels of

technical understanding. The way to do basic tasks, as well as what task the user should

do next, should be obvious.

Definitions

● Beacon: estimote beacon

● installation: a set of beacons

● Project: a particular exhibit associated with an installation of beacons, e.g. gentrification,

mass incarceration, sexual assault, hate crimes. Basically just an association between a

(sub)set of beacons, approved items, and users authorized to add items to the project.

● Item: a story, image, video, or other document.

Required parts:

APPENDIX E. WEB APPLICATION REQUIREMENTS DOCUMENT 70

● User management:

○ Login page

○ User administration overview

○ Single user administration page

○ Personal settings page

● Beacon management:

○ Beacon overview

○ Settings page for a single beacon

○ Map view

● Item management

○ Upload new item page

○ Edit item page

○ Item browser (w/ filtering: view all items associated with a project, view new

items...)

● Project management

○ New project page

○ Edit project page

■ Edit associations between beacons and items

○ Project admin overview

Timeline:

1. Feb. 12: First draft of design mockup due.

○ We’ll give Abdullah feedback.

2. Feb. 19: 2nd draft

○ We’ll either approve the design or give more feedback

3. March 1: If deemed necessary, third draft of mockup due. If not, progress check-in

4. March 18: First working prototype for design due.

○ This should implement the majority of the required parts. There can be rough

edges and parts that are in-progress, but at this point the contours of the design

and most major functionality should be set.

○ We’ll test it out and give Abdullah feedback

5. April 1: Second prototype due

○ Every part should be implemented. The rough edges should be sanded, if not

painted and clear-coated. Everything after this should be polish.

6. April 14: Progress check-in

7. April 29: Final design due.

Tech specs

● The webapp is written in Python. We’re using Flask as the framework for the webapp.

The template language used is Jinja.

● I’m happy to make changes to the backend to accommodate Abdullah’s needs if

necessary.

● After completion code will be released under an open source license

Bibliography

[1] Sarah Perez, Majority Of Digital Media Consumption Now Takes

Place In Mobile Apps, http://techcrunch.com/2014/08/21/

majority-of-digital-media-consumption-now-takes-place-in-mobile-apps/.

[2] Dave Chaﬀey, Mobile Marketing Statistics compilation, http://www.

smartinsights.com/mobile-marketing/mobile-marketing-analytics/

mobile-marketing-statistics/.

[3] Kathryn Zickuhr, Location-Based Services, http://www.pewinternet.org/2013/09/

12/location-based-services/.

[4] Gartner IT, Context-Aware Computing, http://www.gartner.com/it-glossary/

context-aware-computing-2/.

[5] Wikipedia, Beacon, https://en.wikipedia.org/wiki/Beacon.

[6] Anind Dey and Gregory Abowd, Towards a Better Understanding of Context and

Context-Awareness, ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-22.pdf.

[7] Margaret Rouse, GNSS (Global Navigation Satellite System), http:

//searchnetworking.techtarget.com/definition/GNSS.

[8] Wikipedia, Satellite Navigation, https://en.wikipedia.org/wiki/Satellite_

navigation.

[9] Devika Girish, iBeacon vs NFC vs GPS: Which Indoor Location Technology

will your Business Beneﬁt from?, http://blog.beaconstac.com/2015/07/

ibeacon-vs-nfc-vs-gps-which-indoor-location-technology-will-your-business-benefit-from/.

[10] Roy Want, Andy Hopper, Veronica Falcao, and Jonathan Gibbons, The Ac-

tive Badge Location System, http://alumni.media.mit.edu/

dmerrill/badge/

Want92_ActiveBadge.pdf.

[11] AT&T Laboratories Cambridge, The Bat Ultrasonic Location System, http://www.

cl.cam.ac.uk/research/dtg/attarchive/bat/.

Bibliography 72

[12] Suzanne Ross, Wherever You Go, There Is Connectivity, http://research.

microsoft.com/en-us/projects/radar/.

[13] Wikipedia, Bluetooth, https://en.wikipedia.org/wiki/Bluetooth/Origin.

[14] Jimbo, Bluetooth Basics, https://learn.sparkfun.com/tutorials/

bluetooth-basics.

[15] Greg Sterling, Jules Polonetsky, and Stephany Fan, Understanding Beacons: A

Guide to Beacon Technologies, https://fpf.org/wp-content/uploads/Guide_To_

Beacons_Final.pdf.

[16] Apple Inc., Getting Started with iBeacon, https://developer.apple.com/ibeacon/

Getting-Started-with-iBeacon.pdf.

[17] Cooper Smith, THE BEACONS REPORT: Growth Forecasts

For The Most Important Retail Technology Since The Mo-

bile Credit Card Reader, http://www.businessinsider.com/

beacons-are-the-most-important-new-retail-tech-2014-7.

[18] Trip Reddy, 15 Companies From Airports to Retail Already Us-

ing Beacon Technology, https://www.umbel.com/blog/mobile/

15-companies-using-beacon-technology/.

[19] Chantal Tode, Schlaﬂy Beer brews beacon marketing program using beer taps, http:

//www.mobilemarketer.com/cms/news/software-technology/22557.html.

[20] David Nield, iBeacon technology powers a new Smart Pub-

lic Transport project in Bucharest, http://www.gizmag.com/

ibeacon-smart-public-transport-bucharest/37901/.

[21] Serena Chu, Apples iBeacon Tech Brings Art Gallery To Life, http://www.psfk.

com/2014/01/apple-ibeacon-rubens-house.html.

[22] Galen Gruman, Beacons are harder to deploy than you

think, http://www.infoworld.com/article/2983166/bluetooth/

beacons-are-harder-to-deploy-than-you-think.html.

[23] Craig Gilchrist, iBeacon security: understanding the risks, http://blog.estimote.

com/post/104765561910/ibeacon-security-understanding-the-risks.

[24] Ron Amadeo, Meet Googles Eddystonea ﬂexible, open source

iBeacon ﬁghter, http://arstechnica.com/gadgets/2015/07/

meet-googles-eddystone-a-flexible-open-source-ibeacon-fighter/.

[25] Wikipedia, Client-server model, https://en.wikipedia.org/wiki/

Client-server_model.

[26] Jakob Jenkov, Client-Server Architecture, http://tutorials.jenkov.com/

software-architecture/client-server-architecture.html.

[27] Tutorials Point, Flask Tutorial, http://www.tutorialspoint.com/flask/.

[28] Alex Coleman, Model-View-Controller (MVC) Explained

– With Legos, https://realpython.com/blog/python/

the-model-view-controller-mvc-paradigm-summarized-with-legos/.

Bibliography 73

[29] Matthew S.Gast, Building Applications with iBeacon: Proximity and Location Services

with Bluetooth Low Energy, O’Reilly Media.

[30] Noah Elkin, Beacons to Shine a Light on Consumers Murky

Path to Purchase, http://streetfightmag.com/2015/11/24/

beacons-to-shine-a-light-on-consumers-murky-path-to-purchase/.

[31] Shubbi Mittal, Wi-Fi meets iBeacon Technology, http://blog.beaconstac.com/

2015/12/wi-fi-meets-ibeacon-technology/.